@sidorovanthon rebase main pls, after that I'll review again

@miguel-heygen rebased onto current main and re-scoped the PR.

The original diff predated your linkOrCopyFrameDir symlink→copy fallback and largely duplicated it. On a fresh main that fallback is already there, so I dropped the duplication and kept only the part main doesn't cover: a junction attempt between the symlink and the copy.

A Windows junction needs neither Developer Mode nor Administrator, so the common no-privilege case now stages the frame dir at link speed instead of copying every frame (your own comment flags the copy as "measurably slower"). The copy stays as the last resort for mounts with no link support at all (SMB/NFS/exFAT), where even a junction fails with a capability error; a non-capability junction error (e.g. ENOSPC) still propagates. POSIX behavior is unchanged — that tier is only reached on a privilege error POSIX never raises.

Title/description updated to match. Ready for another look.

@miguel-heygen thanks - you were exactly right, the junction ladder was dead code on the very platform it targeted. Rebased onto current main and closed the class in this push (33e0789b0).

Root cause. The local render invoked the extract stage with materializeSymlinks: shouldCopyExtractedFrames(process.platform), and shouldCopyExtractedFrames("win32") is true. stageExtractedFrameDirOnce(..., true) calls cpSync(recursive) directly, so neither the plain-symlink nor the junction tier in linkOrCopyFrameDir ever ran. The helper tests passed while the production caller still selected the old path - precisely as you noted.

Fix:

1. renderOrchestrator.ts - the local in-process render now passes materializeSymlinks: false, routing win32 through the symlink → junction → copy ladder. A junction needs neither Developer Mode nor admin, so the common no-privilege case stages at link speed; the recursive copy stays as the ladder's last resort (SMB/NFS/exFAT).
2. Deleted shouldCopyExtractedFrames - the platform → copy coupling is exactly what bypassed the ladder, and the junction tier now owns the win32 privilege case. Removing it makes the bypass structurally impossible to reintroduce; its JSDoc on materializeSymlinks now spells out "distributed plan() only — do not recouple to process.platform."
3. plan.ts unchanged - distributed staging keeps materializeSymlinks: true (a planDir must be self-contained; symlinks/junctions don't survive S3/GCS).
4. Orchestrator-level regression - added at runExtractVideosStage (the stage the orchestrator actually calls, not a helper): the local path does not request an eager copy (flag false or omitted → materializeExtractedFramesForCompiledDir reaches the ladder), and only the distributed path does. Existing junction fast-path helper test already proves false + EPERM → junction, no copy - so the full chain is covered.

Behaviorally a strict improvement: the ladder's tier 3 is the same cpSync(recursive), so the win32 worst case is identical to today, best case is a privilege-free junction.

Verification (Windows): producer unit lane 306 passed; renderOrchestrator.test.ts 143/143 (junction ladder intact); extractVideosStage.test.ts 7/7 incl. 3 new; tsc --noEmit, oxlint, oxfmt, test-classification all clean. (One unrelated pre-existing failure in hyperframeRuntimeLoader.test.ts - a Windows path-separator assertion - reproduces without this change.)

Ready for another look.